This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
Navigation systems that allow for electronic device location determination are becoming increasingly widespread. There are currently a number of such navigation systems, including Global Navigation Satellite Systems (GNSS) such as the Global Positioning System (GPS), the Russian GLObal NAvigation Satellite System (GLONASS), the Satellite-Based Augmentation System (SBAS), the Local Area Augmentation System (LAAS), the Quasi-Zenith Satellite Systems (QZSS), and the future European system, Galileo. An exemplary GNSS can comprise a network of satellites that broadcasts navigation signals including time and distance data. GNSS receivers pick up these broadcasted navigation signals and calculate a precise global location based thereon.
One aspect of GNSS involves relative positioning. Relative positioning is a positioning technique in which one device is positioned with respect to another device. The goal of this positioning technique is to accurately determine the relative position (not necessarily the absolute position) or the baseline (the vector distance and direction between devices relative to each other) between the two devices. Relative positioning can be performed between two terminals or between a terminal and a reference station. In addition, relative positioning can be performed in a multi-baseline environment, where baselines are determined between multiple devices.
The simplest form of relative positioning involves determining the positional difference between two devices. Most relative positioning, however, involves high accuracy methods that generally achieve sub-decimeter (sub-dm) accuracies. One such commercially-deployed high accuracy positing method is Real-Time Kinematic (RTK). RTK is based on obtaining continuous periodic carrier and/or code phase measurements from two GNSS receivers, which can be terminals, virtual reference receivers (VRRs), and/or physical reference receivers, and linearly combining the measurements from the receivers in such a way that common mode errors cancel. For instance, when the baseline is short, atmospheric errors (troposphere, ionosphere) cancel almost completely.
In professional use, dual-frequency GPS receivers are typically used for relative positioning. The dual-frequency capability allows for, e.g., compensating the residual ionosphere errors. Alternatively, and in instances when the baseline is short and the common mode errors can be assumed to cancel, single-frequency receivers may be used. Accordingly, the shorter the baseline, the more straightforward and simpler solving the baseline accurately becomes.
As mentioned, positioning measurements can be made between terminals and VRRs. VRRs are computation reference receivers that are generated at a desired location and provided via a VRR Service to the requestor. In some instances, the VRR Service generates a single VRR on request to a desired location. In other instances, the VRR Service provides a large number of VRRs in a static grid. Thus, when a terminal needs to be positioned with respect to a VRR, the VRR closest to the terminal is chosen from the static grid. It should be noted that VRRs require the knowledge of the coarse location of the device to be positioned. This coarse location can be obtained using the conventional Assisted GNSS (AGNSS).
In one conventional deployment option, a VRR Service provider can operate a network of physical GNSS receivers to obtain reference measurements. These reference measurements can be used to enable the VRR Service provider to generate a VRR at any given location within the area covered by the GNSS network. The advantage of this is that a VRR can be generated at the location of the terminal to be positioned relative to the VRR. Hence, the baseline will be very short, and because of its computational nature, the location of the VRR is known very accurately. Thus, solving the baseline between the VRR and the terminal allows for determining the absolute location of the terminal at a very high accuracy level.
Within the context of Long Term Evolution (LTE), the 4th generation of radio technology, GNSS-based positioning includes the LTE Positioning Protocol (LPP). Architecturally speaking, LPP is a protocol between a “target” and “server.” The target is generally the User Equipment (UE) to be positioned, and the server is generally the node that provides the positioning instructions and assistance data to the target. It should be understood that “UE,” as used herein, is intended to be an exemplary target. Furthermore, it should be understood that UEs can serve as both targets and servers from the LPP point of view. For example, in relative positioning between two UEs, one UE might be considered the server and the other UE might be considered the target. In this arrangement, the UE functioning as the server may request for code/carrier phase measurements from the other UE functioning as the target. The UE functioning as the server can thereby determine the baseline between the two UEs at a high accuracy based on the code/carrier phase measurements from the UE functioning as the target.
For high accuracy positioning to occur, a constant stream of reference measurement assistance data should flow from the server to the target. In the LPP specification (described in “3GPP TS 36.355 Stage 3” found on the 3GPP website), this occurs by the target sending a request referred to as a LPP Request Assistance Data message to the server. The server receives this message and responds with a LPP Provide Assistance Data message. Although the LPP specification allows for multiple successive LPP Provide Assistance Data messages, a target currently cannot request such continuous periodic assistance.
In addition to the typical “Request”-“Provide” interaction, the LPP specification also allows for the unsolicited provision of assistance data, wherein the server pushes assistance data to the target without the target first requesting it. This is useful when that the server knows that the target will likely request certain assistance data, e.g., in a UE-based GNSS-based session, in which the server can be sure that after commanding such a positioning method, the target will request for ephemerides. Thus, the server can act pro-actively and push the assistance data to the terminal without an explicit request.
In the LPP specification, the messaging is based on transactions within a LPP session. A LPP session is used to support a single location request and consists of transactions that each perform a single activity. For example, in the case of UE-initiated assistance data delivery, the LPP transaction consists of the LPP Request Assistance Data message (target to server) and one or more LPP Assistance Data Provide messages (server to target). That is, the LPP transaction consists of one request and one or more provide messages (or, in the unsolicited case, one or more provide messages).
In instances when a target needs to be positioned accurately with respect to a particular VRR (i.e., VRR-based relative positioning), there are at least two alternative deployments options. In a first deployment option, the VRR Service provides the Secure User Plane Location Protocol Location Platform (SLP) with a static grid of VRRs. For instance, the VRR service might provide the SLP with VRRs in a 10-km grid for a certain geographical area. When the target then needs to be positioned, the server selects the VRR closest to the target and starts providing reference measurements from that VRR to the target. In a second deployment option, the VRR is dynamically generated based on the request from the target, and measurements are provided with respect to that VRR.
Given the mobile nature of the various nodes involved in LPP, there are situations in which it is necessary and/or beneficial to change the target's associated VRR. For example, the VRR may need to be changed when the distance between the VRR and the target is too great due to, e.g., target movement. This is especially true in cases where the target is a single frequency receiver and thus requires a short baseline to keep good quality (as mentioned above). Another example of when the VRR may need to be changed occurs when the line of sight between the satellite and target deteriorates. For example, when the visibility between the satellite and the target is low, or when it is beneficial to have the baseline pointing in a certain direction, the target may decide to change the VRR to get a more stable baseline.